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METHOD AND APPARATUS FOR INTEGRATING A VOICE GATEWAY 
WITH AN IP/PBX TELEPHONE SYSTEM 

• 5 

/~ 

Cross Reference to Related Applications 

1 0 This application claims priority from United S tates Provisional Patent Application 

Serial Number 60/143,817 filed July 14, 1999. 

Field 

The present invention relates generally to communication systems and in particular 
15 to a hybrid communication system that integrates an IP/PBX telephone system with a 
communication system having an internet protocol (IP) network to and a public switched 
telephone network (PSTN) provide unified voice-mail to users of IP telephones. 

Background 

20 Telephony, that is voice communication over an internet protocol (IP) network, 

has gained rapidly in popularity in recent years among both businesses and individuals 
seeking to minimize the cost of the long distance telephone calls. IP telephony systems 
are described in, for example, commonly assigned co-pending U.S. Patent application 
serial number 09/061,802, which is incorporated herein by reference. An IP telephony 

25 system typically includes ah IP network, such as a wide area network (WAN), a local area 
network (LAN), or the Internet, with a number of IP telephones connected thereto. The 
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IP telephones can be a stand-alone IP telephone directly connected to the IP network, or 
a computer workstation with a speaker, microphone and IP telephony software to function 
as an IP telephone. In addition, the EP telephone can be coupled to the public switched 
telephone network (PSTN) through a voice gateway that translates between data packets 
used by IP networks and analog signals used by the PSTN . 

One of the problems with current telephony systems, particularly for business 
users, is their inability to integrate with existing communication networks, such as a 
private branch 1 exchange (PBX). PBXs, which are well-known and widely used within 
government and industry, are telecommunications switching systems maintained at one 
or more user, sites that are used to connect internal station to station telephone calls and 
to the PSTN. In addition, many PBXs provide the users with advanced features such as 
caller ID, call forwarding, call conferencing, and voice-mail etc. These features have 
come to play a vital role in business*, enabling the users to remain in contact with and 
better serve their clients and customers. The IP telephones of conventional telephony 
systems do not connect to a PBX at all, coupling instead to the PSTN through a gateway 
server, as described above, therefore these advance features are not available to users of 
IP telephones. Moreover, those systems that do couple to a PBX , as for example taught 
in U.S. Patent No. 5,867,494, to Krishnaswamy et al„ merely teach a voice trunk-through 
which voice and touch-tone (DTMF) signals may be bridged between an IP network and 
the PSTN via the PBX. Such a path cannot alone function to enable an IP telephone user 
to. access the.adyanced features .of the PBX. .Thus, there is a need for an.IP telephony 
system capable of being integrated with conventional existing PBX systems, to make the 
advanced features of the PBX available to IP telephone users. 

Summary 

The present invention relates to an apparatus and method for integrating a voice 
gateway system to incorporate an IP/PBX telephone system. This enables users of IP 
telephones to access many of the features of the gateway network. 

• It is an object of the invention to provide an integrated voice gateway system 
which provides both PBX telephone users and IP telephone users with a common voice- 
mail system, which supports voice-mail feature transparency for all of the telephone users. 
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It is an object of the invention to provide an integrated voice gateway system with 
an IP/PBX telephone system, where the IP telephones of the IP/PBX telephone network 
are used typically by the employees within a company. This gateway system can route a . 
voice telephone call between parties at two different locations over a WAN IP network, 
5 . where either or both parties are "using a PBX telephone or an IP telephone. It is a further 
object of the invention that the gateway system will automatically select which of the IP 
network or PSTN over which to route the calls. 

It is a further object of the invention to provide a system which can route a 
telephone call between a calling party using an IP telephone at a first location within the 
1 0 system to a second location within the system via a WAN IP network, and then from the 
' second location to a called party at a third location via the PSTN. 

It is an object of the invention to provide an integrated voice gateway system 
which can place a telephone call over an IP network, and then if, during the telephone 
call, the quality of the telephone call falls below a predetermined quality level, and the 
1 5 quality degradation is determined to be due to the WAN IP network performance, to be 
able to reroute the telephone call over to the PSTN, and to do so in a manner that is 
transparent to both the calling and called parties, either or both of which can be using an 
IP telephone. 

It is an object of the invention to provide an integrated voice gateway, system 
20 which can track any modifications to a profile of any telephone user in the enterpnse. A 
telephone user includes users of PBX telephones and IP telephones. Modifications to the 
telephone user profile may include changes to the existing data for a user, addition of new 
users, and deletion of users. It is a further object of the invention to provide an integrated 
• voice gateway system which can integrate with an enterprise directory to allow single 
25 point of entry for user profile modifications and to provide replication of these changes 
across all enterprise sites. 

It is an object of the invention to provide an integrated voice gateway system in 
which the identification of the calling party (e.g., name, title, department, primary 
telephone number) can be displayed on the called telephone's display, where the called 
30 party is using an IP telephone, and said telephone supports caller ID display. Likewise, 
the identification of .the calling parry can be displayed on any other telephone in the 
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integrated voice gateway system, where the calling party is using an IP telephone. In 
addition, the format of the displayed caller ID information is the same for all said 
telephones. 

It is an object of the invention to provide an integrated voice gateway system in 
which the identification of the calling party (e.g., name, title, department, primary 
telephone number) is displayed on a computer screen (rather than on a telephone display) 
co-located with the called party's telephone, and that such information be displayed 
regardless of the vendor(s) supplying the telephone equipment used by the calling and 
■called parties. Either or both of the calling and called parties may be using an IP 
telephone. It is further an object of the invention that such information be provided 
regardless of the desktop workstation or PC (workstation and PC are referred to 
interchangeably herein), or operating system used via a WWW browser interface. 

It is an object of the invention to provide an integrated voice gateway system 
which can create a log of incoming telephone calls and call attempts arriving over a WAN 
IP network, and of outgoing telephone calls and call attempts routed over the WAN IP 
network, and identify the names of calling and called parties. It is a further object of the 
invention to provide a log of all incoming and outgoing calls whether the calling and 
called parties are using a .PBX telephone, using a PSTN telephone, or using an IP 
telephone. 

It is an object of the invention to provide an integrated voice gateway system in 
.which,, when .a called.party's telephone, is busy, the system can automatically setup .a .call 
between the calling party and the called party as soon as the called party hangs up, and 
either or both of calling party and called parry can be using a IP telephone. It is a further 
object of the invention to provide such a capability even when a called party has voice- 
mail. 

It is an object of the invention to provide an integrated voice gateway system in 
which, when a called party is busy, the calling party may send a computer message which 
will be immediately displayed on a computer screen co-located with the called party's 
telephone, for example to explain why the calling parry needs to speak with the called 
parry, and one or more of the parties arousing an IP telephone. 

•It is an object of the invention to provide an integrated voice gateway system in 
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which, when a called party does not answer an incoming telephone call, the calling party 
may forward, the call, for example to voice mail, or to an answering station (e.g. a 
receptionist or other designated party), and the calling party and/or the called party can 
be using an IP telephone. It is further an object of the invention to provide the capability 
for a party at an answering station to send a computer .message which will immediately 
be displayed on a computer screen co-located with the called party's telephone. 

It is an object of the invention to provide an integrated voice. gateway system in 
which a user of the system may set up the system to forward that user's telephone calls 
to a different telephone. It is a further object of the invention to forward calls to a PSTN 
telephone, a cellular telephone in a public wireless network, an IP telephone, a PC-based 
IP telephone, or a private mobile telephone. It is a further object of the invention to 
provide the capability for a user to set up the system -to forward that user's telephone calls 
to different telephones according to a time schedule predetermined by the user. It is a still ■ 
further object of the invention to provide the capability for a user to set up the system to 
forward telephone calls originating only from one or more calling parties so designated 
by the user. It is a further object of the invention to provide the capability to setup call 
forwarding via a browser interface or interactive voice response (IVR). 

Brief Description of the Drawings 

These and various other features and advantages of the present invention will be 
apparent upon reading of the following detailed description in conjunction with the 
accompanying drawings, where: 

FIG. 1 is a schematic diagram showing an embodiment of high-level network 
architecture for various gateway network configurations; 

FIG. 2 is a schematic diagram showing an embodiment of a gateway network 
configuration which includes a gateway server, aPBX telephone system and an IP/PBX 
telephone system; 

FIG. 3 A is a schematic diagram showing call routing for a telephone call made 
between a PSTN telephone and an IP telephone in the same locale according to an 
embodiment of the present invention; 

FIG. 3B is a schematic diagram showing call setup sequence for a telephone call 
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made from an IP telephone to a PSTN telephone along the route shown in FIG. 3A;. 

FIG. 3C is a schematic diagram showing call setup sequence for a telephone call 
made from a PSTN telephone to an IP telephone along the route shown in FIG. 3 A; 

FIG. 4A is a schematic diagram showing call routing for a telephone call made 
between a PBX telephone and an IP telephone in the same locale according to an 
embodiment of the present invention; 

FIG. 4B is a schematic diagram showing call setup sequence for a telephone call 
made from an IP telephone to a PSTN telephone along the route shown in FIG. 4A; 

FIG. 4C is a schematic diagram showing call setup sequence for a telephone call 
. made from a PBX telephone to an IP telephone along the route shown in FIG. 4 A; 

FIG. 5 A is a schematic diagram showing call routing for a telephone call made 
between one IP telephone and another IP telephone in the same locale according to an 
embodiment of the present invention; 

FIG. 5B is a schematic diagram showing call setup sequence for a telephone call 
made from one IP telephone to another IP telephone along the route shown in FIG. 5 A; 

FIG. 5C is a schematic diagram showing an alternate call setup sequence, for a 
telephone call made from one IP telephone to another IP telephone along the route shown 
in FIG. 5A; 

FIG. 6A is a schematic diagram showing call routing for a telephone call made 
between a PSTN telephone and ari IP telephone, with the two telephones in different - 
. locales, according. to an embodiment.of. the present.inyention; . ,,. 

FIG. 6B is a schematic diagram showing call setup sequence for a telephone call 
made from an IP telephone to a PSTN telephone along the route shown in FIG. 6A; 

FIG. 6C is a schematic diagram showing call setup sequence for a telephone call 
made from a PSTN telephone to an IP telephone along the route shown in FIG. 6A; 

FIG, 7A is a schematic diagram showing call routing for a telephone call made 
between a PBX telephone and an IP telephone, with the two* telephones in different 
locales according to an embodiment of the present invention; 

FIG. 7B is a schematic diagram showing call setup sequence for a telephone call 
made from an IP telephone to a PBX telephone along the route shown in FIG. 7A; 

FIG. 7C is a schematic diagram showing call setup sequence for a telephone call 
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made from a PBX telephone to an IP telephone along the route shown in FIG. 7 A; 

FIG. 8 A is a schematic diagram showing call routing for a telephone call made 
between one IP telephone and another IP telephone, with the two telephones in different 
locales according to an embodiment of the present invention; 
5 FIG. 8B is a schematic diagram showing call setup sequence for a telephone call 

made from one IP telephone to another IP telephone along the route shown in FIG. 8A; 

FIG. 9 A is a schematic diagram showing call routing for a voice-over-IP telephone 
call made between a PBX telephone at one locale and an IP telephone at another locale 
according to an embodiment of the present invention; 
1 0 FIG. 9B shows the telephone call from FIG. 9A after it has been automatically re- 

routed over the PSTN instead of over the WAN IP network,' due' to degradation in the 
quality of service over the WAN; 

FIG. 1 OA is a schematic diagram showing call setup sequence for a telephone call 
made from a PBX telephone to an IP telephone at that same locale, where a caller using 
15 the PBX telephone is redirected to a called party's voice-mail system, due to lack of 
availability of the called party at the time the call is made; 

FIG. 1 OB is a schematic diagram showing call routing resulting from the call setup 
sequence of FIG. I OA, where the caller has been successful directed to the called party's 
voice-mail system at the same locale; 
20 FIG. 1 1 A is a schematic diagram showing call routing resulting from the call setup 

sequence for a telephone call made from a PBX telephone to an IP telephone at another • 
locale, where the caller has* been successful directed to the called party's voice-mail 
system; 

FIG. 1 IB is a schematic diagram showing call setup sequence for a telephone call 
25 made from the PBX telephone at one locale to the called party's voice-mail system at 
another locale along the route shown in FIG. 1 1 A; 

FIG. 12 shows how the gateway server polls the voice-mail system at regular 
intervals (the interval being configurable) in order to be able to keep the IP telephone 
users' telephones current with regard to whether the voice-mail light on the phone is on 
30 or off; 

FIG. 1 3 A is a schematic diagram showing call routing for a telephone call made 
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between a PBX telephone and an IP telephone at the same locale; 

FIG. 1 3B is a schematic diagram showing call routing for a telephone call made 
between the PBX telephone and an IP telephone at another locale - the condition existing 
following the call transfer operation on the part of the IP telephone being used in FIG. 
13A; 

FrG. 13C is a schematic diagram showing call setup sequence for transferring the 
telephone call from the route used in FIG. 13A to the route shown in FIG. 13B; 

FIG. 14 is a schematic diagram showing call routing for a 3-way conference call 
between a first party at a PBX telephone at a first locale, a second party at an IP telephone 
at a first locale, and a third parry at an IP telephone at a second locale; and 

FIG. 1 5 is a schematic diagram showing call setup sequence for a telephone call 
made from an IP telephone to a PBX telephone at the same locale, where the call dialing 
operation was initiated via a browser-based GUI that is associated with the IP telephone. 

Detailed Description 

FIG. 1 schematically illustrates an enterprise network according to an embodiment 
of the present in vention for passing voice and data communication between a number of 
different sites within an enterprise or company. The enterprise network typically includes 
one or more gateway networks, three which are shown, each having a gateway server, and 
a PBX telephone system, and/or an IP/PBX telephone system. The gateway networks 
. C0 .™K4? i ?? t . e . with each other oyer an internet protocol (IP) network, such as. a wide area 
network (WAN) Network 1 and over the public switched telephone network (PSTN) 2. 

In gateway network 1 0, a gateway server 1 1 operates in conjunction with a PBX 
telephone system 12, coordinating both PBX telephone calls and public switched 
telephone network calls. Gateway networks are described in, for example, commonly 
assigned co-pending U.S. Pat. Application 09/061,802, which is incorporated herein by 
reference. ' 

Gateway network 20, includes an IP/PBX telephone system 23 that supports IP 
telephones (not shown) which can be either stand-alone devices or incorporated into 
computer work stations. The gateway server 2 1 coordinates the activities of all the 
companyrintemal telephone systems: the PBX telephone system 22 and the IP/PBX 
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telephone system 23. This gateway network 20 configuration is of particularly useful 
where both PBX and IP telephones are used. 

In gateway network 30 has an IP/PBX telephone system 33 is present but no PBX 
telephone system. This situation is particularly useful for a small branch office for which 
5 a conventional PBX would be either impracticable or prohibitively expensive. In this 
configuration the gateway server 31 is configured quite differently than in the above 
configurations. Namely, the gateway server 31 includes telephony cards that are 
configured to communicate directly with the PSTN. The gateway server 3 1 coordinates 
the activities the IP/PBX telephone system 33, including its IP telephones and the call 

1 0 routing of said telephones. The gateway server 3 1 may coordinate with another gateway 
server 11,21, in order to provide full services to the users in its network, including for 
example, PBX-based voice-mail. 

FIG. 2 shows a more detailed architecture of gateway network 20 of FIG. 1 . The 
gateway server 21 includes gateway server software 111, a PBX CTI (Computer 

1 5 Telephony Integration) driver 1 1 2, a station/trunk driver 1 1 3 and a VoIP (Voice over IP) 
driver 1 14. The gateway server software 1 1 1 manages call set up and routing, access to 
a directory server 28, user graphical user interface (GUI) updates via a web server, and 
queries and updates to a database of user profiles and call information. In addition, the 
gateway server software 111 contains an IP/PBX CTI driver 115, which is a piece of 

20 interface software used whenever an IP/PBX call manager 40 is addressed. In the 
remainder of the description, this piece of software, the IP/PBX CTI driver 115, is 
implicitly assumed to be involved with every interaction between the gateway server 
software 1 1 1 and the IP/PBX call manager 40 and therefore, for simplicity, will not be 
shown in the other drawings , The IP/PBX CTI driver 1 15 is. implemented so as to adhere 

25 to various interface standards, including by not limited to the Microsoft-touted standard 
TAPI (Telephony Application Programming Interface). 

The gateway server software 1 1 1 uses the PBX CTI driver 1 1 2 software to 'support 
advanced call control and voice-mail access functions. The PBX CTI driver 1 12 software 
is typically supplied by (and is specific to) the PBX vendor. The PBX CTI driver 1 12 

30 communicates with the PBX 30 via the local area network .(LAN) 3 connection. The 
station/trunk driver 1 13 consists of hardware and software that manage a trunk interface 
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and an analog station interface to the PBX 30. The VoIP driver 1 14 consists of hardware 
and software that handles the conversion between the voice data in the format required 
for the station/trunk driver ,1.1 3 telephony interface and the IP packet format required by 
the WAN IP network 1 . The VoIP driver 1 14 is also referred to as simply the gateway, 
as converting voice data between the IP and switched circuit network (SCN), such as the 
PSTN, is its' fundamental function. 

The PBX 30 provides the interface to the PSTN 2. Continuing to refer to FIG. 2, 
the PBX telephone system 22 consists of the PBX 30 and one or more PBX telephones 
3 1 . Operation of the PBXs and PBX telephones is well known and is discussed in detail 
in co-pending, commonly assigned U.S. patent application number 09/061,802, which is 
incorporated herein by reference. The voice-mail system operates in conjunction with the 
PBX 30. Proper operation of voice-mail server 32, requires CTI driver 112. 

FIG. 2 also shows an embodiment of an IP/PBX telephone system 23 which is 
managed by a centralized server called the IP/PBX call manager 40 according to. the 
present invention. The IP/PBX call manager 40 may reside on its own server platform (as 
shown), or it may reside on the same platform as the gateway server 21. 

Typically, the users of the IP/PBX telephone system 23 are equipped with one of 
(1 ) an IP telephone 4 1 , (2) an IP telephone 4 1 and a work station 50, or (3) a work station 
1 50 that has a built-in IP telephone 1 4 1 . The IP/PBX call manager 40 first receives a call 
setup request from an IP telephone user who initiates a call on the IP telephone 41 or 14 1 . 
.If the.call. is for an extension representing another IP telephone 4 1 or 141 coupled to the 
IP/PBX telephone system 23, the IP/PBX call manager 40 connects the two IP telephones 
so the call can take place. To set up the connection the IP/PBX call manager 40 
exchanges information with the gateway server software 111 including caller ID 
information (normally stored at the gateway server 21). In addition, the gateway server 
software 1 1 1 can log the start of the call to a call log (not shown). If a call is initiated 
with dialed digits that are not known to the IP/PBX call manager 40, then the IP/PBX call 
manager 40 passes the call setup request to the gateway server software 111. The gateway 
server software 1 1 1 then determines how to route the call, sets up the other leg of the call, 
and then returns the information to the IP/PBX call manager 40 of the IP address where 
the IP telephone 41 or 141 needs to route the IP packets. 

-10- 
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Throughout the rest of this description, whenever the term "IP telephone" is used, 
it is understood that this can mean either a stand-alone telephone device or a telephone 
that is built into a workstation, and these two can be used interchangeably when 
discussing the function of-an "IP telephone". 
5 Call Routing and Setup for IP Telephone Calls 

There are a number of different paths- that must be considered for routing a call 
involving an IP telephone in IP/PBX telephone system. The different routing paths and 
the sequence of steps required to establish these routings are described in the next 
paragraphs. 

1 o In FIG. 3 A an in-progress call is shown between an IP telephone operating in the 

local network and a PSTN telephone at a location nearby the gateway network's location. 
Starting with the caller IP telephone 141, the voice data is converted to IP. packets there 
and placed onto the LAN where it is received by the VoIP driver 1 14 of the gateway 
server 110. At the VoIP driver 1 14, the data is removed from the IP packets and the data 

15 decoded from whatever encoding and compression format was applied by the caller IP 
telephone 141. The voice data is then routed via the station/trunk driver 1 1 3 to the PBX 
1 30, and the PBX 30 which in turn routes it in an analog format to the PSTN 1 02 and on 
through to the PSTN telephone 104. 

The voice which travels from the called PSTN telephone 104 to the caller using 

20 IP telephone 141 follows the same path, but goes through the process in reverse; at the 
VoIP driver 1 14, the voice data is encoded and inserted into IP packets. The data from 
the IP packets are extracted and decoded by the IP telephone 141. 

It should be noted that the same routing path would result if the caller is the PSTN 
telephone user and the called party is the IP telephone user. - - - 

25. In considering how a call such as that shown in FIG. 3A is setup, there are two 

variations that may be considered, which will result in different sequences of steps in the 
call setup process. The two variations are (1) when the caller is using the TP telephone 
1 4 1 and the called party is using the PSTN telephone 1 04, and (2) when the caller is using 
the PSTN telephone and the called party is using the IP telephone. 

30 The call setup sequence for the caller using an IP telephone calling to a user of a 

PSTN telephone is shown in FIG. 3B and described in the subsequent text. Note that in 

-*11 - ■ 
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FIG. 3B, and throughout the remainder of the description, the numbered steps are 
illustrated in the figures by arrows labeled with a corresponding number. 

1. • User dials on a keypad of the IP telephone 141. The IP telephone 141 
communicates with the IP/PBX call manager 140 to request call setup. (Step 301) 
5 2. The IP/PBX call manager 140 communicates to the gateway server 

software 111 that call setup is requested by an IP telephone 141. The IP/PBX call 
manager 140 receives the addressing information of the IP telephone 141 in the 
communication. The gateway server software 1 1 1 checks the directory server 28 (shown 
in FIG. 2), and verifies the user's privilege to access the PSTN 2. (Step 302) 
10 3 - The gateway server software 1 1 1 communicates call setup request to the 

station/trunk driver 1 13. (Step 303) 

4. The station/trunk driver 113 communicates the setup request to the PBX 
• 30. (Step 304) 

5. The PBX 30 dials to the PSTN telephone 104 via the PSTN 102, and the 
1 5 calling party answers the telephone. (Step 305) 

6. The gateway server software 1 1 1 configures its VoIP driver 1 14 to begin 
transmitting voice packets to the address of the IP telephone 141. (Step 306) (Note that 
step 306 can be done at the same time as steps 303-305.) 

7. The gateway server software 1 1 1 informs the IP/PBX call manager 140 
20 that the call is going through and provides the addressing information for its VoIP driver 

.,1,14., (Step 307).. , .. . . .,. .._ . ts ... . ., , , , . 

8. The IP/PBX call manager 140 informs the IP telephone 141 that the call 
is going through and passes the addressing information for the VoIP driver 1 14. The IP 
telephone is then ready to begin transmitting voice packets to the VoIP driver 1 14. (Step 

25 308) 

The call setup sequence for the caller using a PSTN telephone 1 04 calling to a user 
of an IP telephone 141 is shown in FIG. 3C and described in the subsequent text. 

1. A user of the PSTN telephone 104 dials an IP telephone user at the 
company facility with a direct inward dialing (DID) number. The call is routed via the 
PSTN 1 02 to the PBX 1 30. (Step 401) 

2. " The PBX 30 routes the call to the station/trunk driver 113. (Step 402) 

-12- 
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3. The station/trunk driver 113 routes the call setup request to the gateway 
server software 111. (Step 403) 

4. The gateway server software 1 1 1 checks its database and finds that the user 
being dialed has an IP telephone managed by the IP/PBX call manager 140. The gateway 
server. so frware 1 1 1 routes the call setup, request to the IP/PBX call manager 140, and it 
attaches the addressing information of its VoIP driver 114, since the gateway server 
software 1 1 1 determines that the voice stream will need to be routed via that driver. (Step 
404) 

5. The IP/PBX call manager 1 40 finds that the particular IP telephone 141 is 
not currently in use, and thus forwards the call setup request, along with the addressing 
information of the VoIP driver 114, to the IP telephone 141. The IP telephone 141 
configures itself to begin routing IP voice packets to the VoIP driver 1 14 in the event that 
the called party answers the call. (Step 405) 

6. The IP/PBX call manager 140 sends and acknowledgment back to the 
gateway server software 111, including the addressing information of the IP telephone 
141. (Step 406) 

7. The gateway server software 111 commands its VoIP driver 114 to 
configure itself to begin sending voice packets to the IP telephone 141. (Step 407) 

8. The gateway server software 1 1 1 configures the station/trunk driver 113 
to route the voice stream to the VoIP driver 1 14. (Step 408) 

FIG. 4A shows the call routing for a telephone call made between a PBX 
telephone and an IP telephone in the same locale. 

FIG. 4B shows the call setup sequence for a telephone call made from an IP 
telephone to a PBX telephone in the same locale. The call setup sequence is as follows: 

1 . A user of the IP telephone 141 dials, and the IP telephone 141 sends a call 
setup request to the IP/PBX call manager 140. (Step 501) 

2 . The IP/PBX call manager 1 40 receives the call setup request and forwards 
it to the gateway server software 111. (Step 502) 

3 . The gateway server software 1 1 1 checks its database and finds the called 
party has a PBX telephone 13 1, so it sends a call setup request to the station/trunk driver 
113. • (Step 503) • 
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4. The station/trunk driver 1 13 forwards the call setup request to the PBX 
130. (Step 504) 

5. The PBX 130 calls the PBX telephone 13 1 of the called party. (Step 505) 

6. The gateway server software. 1 1 1 configures its VoIP driver with the 
address of the IP telephone 1 4 1 , and the VoIP driver gets ready to start transmitting voice 
IP packets to that address. (Step 506) 

7. The gateway server software 1 1 1 responds back to the IP/PBX call 
manager 140 that its part of the call has been successfully setup, and it forwards the 
address of its VoIP driver 1 14. (Step 507) 

8. The IP/PBX call manager 140 responds to the IP telephone 141, 
forwarding it the address of the VoIP driver 1 14. The IP telephone 141 then configures 
itself to begin routing. IP voice packets to the VoIP driver 1 14. (Step 508) 

The call setup sequence for the caller using a PBX telephone calling to a user of 
an IP telephone is shown in FIG. 4C and described in the subsequent text. 

1. A user of the PBX telephone 131 dials an IP telephone user at the same 
company facility using the extension only to dial, or using an on-net number. The call is 
routed to the PBX 130. (Step 601) 

2. The PBX 30 routes the call to the station/trunk driver 113. (Step 602) 

3 . The station/trunk driver 1 1 3 routes the call setup request to the gateway 
server software 111. (Step 603) 

4 - T . he gatewayserver software 1 1 1 checks its database and finds that the user 
being dialed has an IP telephone managed by the IP/PBX call manager 140. The gateway 
server software 1 1 1 routes the call setup request to the IP/PBX call manager 140, and it 
attaches to the request the addressing information of its VoIP driver 114, since the 
gateway server software 1 1 1 determines that the voice stream will need to be routed via 
that driver. (Step 604) 

5. The IP/PBX call manager 140 finds that the particular IP telephone 141 is 
not currently in use, and thus forwards the call setup request, along with the addressing 
information of the VoIP driver 114, to the IP telephone 141. The IP telephone 141 . 
configures itself to begin routing IP voice packets to the VoIP driver 1 14 in the event that 
the called parry answers the call. (Step 605) 
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6. The IP/PBX call manager 140 sends an acknowledgment back to the 
gateway server software 1 U, including the addressing information of the IP telephone 
141. (Step 606) 

7. The gateway server software 111 commands its VoIP driver 114 to 
5 configure itself to begin sending voice packets to the IP telephone 141 . (Step 607) 

8. The gateway server software 1 1 1 configures the station/trunk driver 1 1 3 
to route the voice stream to the VoIP driver 1 14. (Step 608) 

FIG. 5A shows the. call routing for a telephone call made between one IP 
telephone 14 1 and another IP telephone 241 in the same locale. 
10 FIG. 5B shows the call setup sequence for a telephone call made from one IP 

telephone 141 to another EP telephone 241 in the same locale. 

1 . A user of the IP telephone 141 dials, and the EP telephone 141 sends a call 
setup request to the IP/PBX call manager 140. (Step 701) 

2. The IP/PBX call manager 140 receives the call setup request and forwards 
15 it to the gateway server software 111. (Step 702) 

3 . The gateway server software 1 1 1 checks its database and finds that the user 
being dialed has an IP telephone 241managed by the IP/PBX call manager 140. The 
gateway server software 1 1 1 provides the addressing information to the IP/PBX call 
manager 140. (Step 703) . 

20 4. The IP/PBX call manager 140 begins routing IP voice packets to the IP 

telephone 241 (Step 704) and to IP telephone 141 (Step 705). 

FIG. 5C shows an alternate (and less preferred) call setup sequence for a telephone 
call made from one IP telephone 141 to another IP telephone 241 in the same locale. 

1 . A user of the'EP telephone 141 dialsjand the IP telephone 141 sends a call 
25 setup request to the IP/PBX call manager 140. (Step 801) 

2 . The IP/PBX call manager 140 receives the call setup request and finds that 
the user being dialed has an IP telephone 241 managed by the IP/PBX call manager 140. 
(Step 802) 

3. The IP/PBX call manager 140 provides the addressing information to IP 
30 telephone 141; and IP telephone 141 begins routing IP voice packets to IP telephone 241. 

(Step 803) 
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FIG. 6A shows the call routing for a telephone call made between a PSTN 
telephone 104 and an IP telephone 241, with the two telephones in different locales. 

FIG. 6B shows the call setup sequence for a telephone call made from an IP 
telephone 241 to a PSTN telephone 104, with the two telephones in different locales. 

1. .A user of the IP telephone 141 dials, and the IP telephone 141 sends a call 
setup request to the IP/PBX call manager 140. (Step 90 1) 

2. The IP/PBX call manager 1 40 receives the call setup request and forwards 
it to the gateway server software 111. (Step 902) 

3 . The gateway server software 1 1 1 checks its database and finds that the user 
being dialed has a?STN telephone 104 nearby another gateway network 1 10. The 
gateway seiver software 21 1 connects to gateway server software 1 1 1 in the other gateway 
network via the WAN 10 1 . (Step 903) 

4. The gateway server software 111 sends a call setup request to the 
station/trunk driver 113. (Step 904) 

5. The station/trunk driver 1 13 forwards the call setup request to the PBX 
130. (Step 905) 

6. The PBX 1 30 calls the PSTN telephone 1.04 of the called party. (Step 906) 

7. The gateway server software 111 configures its VoIP driver with the 
address of the IP telephone 141, and the VoIP driver gets ready to start transmitting voice 
IP packets to that address. (Step 907) 

8. The gatewayjseryer software 1 1 1 responds back to the. gateway server 
software 211 that its part of the call has been successfully setup, and it forwards the 
address of its VoIP driver 2 14. (Step 908) 

9. The gateway server software 2 1 1 forwards the address of its VoIP driver 
214 to the IP/PBX call manager 240. (Step 909) 

10. The IP/PBX call manager 240 responds to the IP telephone 241, 
forwarding it the address of the VoIP driver 214. The IP telephone 241 then configures 
itself to begin routing IP voice packets to the VoIP driver 1 14. (Step 910) 

FIG. 6C shows the call setup sequence for a telephone call made from a PSTN 
. telephone 104 to an IP telephone 241, with the two telephones in different locales. 

1 . . A user of the PSTN telephone 1 04 dials and sends a call setup request to 
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the PBX 130 via the PSTN 102. (Step 1001) 

2. The PBX 130 routes the call to the station/trunk driver 1 13. (Step 1002) 
.3. The station/trunk driver 1 1 3 routes the call setup request to the gateway 

server software 111. (Step 1003) 

4. The gateway server software 111 checks its database and finds that the user 
being dialed has a PSTN telephone 104 nearby another gateway network 210. The 
gateway server software 1 1 1 connects to gateway server software 21 1 in the other gateway 
network via the WAN 1 0 1 . (Step 1 004) 

5. The gateway server software 2 1 1 checks its database and finds that the user 
being dialed has an IP telephone managed by the IP/PBX call manager 240. The gateway 
server software 211 routes the call setup request to the IP/PBX call manager 240, and it 
attaches to the request the addressing information of its VoIP driver 214, since ttie 
gateway server software 21 1 determines that the voice stream will need to be routed via 
that driver. (Step 1005) . ' 

6. The IP/PBX call manager 240 responds to the IP telephone 241, 
forwarding it the address of the VoIP driver 214. The IP telephone 241 then configures 
itself to begin routing IP voice packets to the VoIP driver 114. (Step 1006) 

' 7. The IP/PBX call manager 240 sends an acknowledgment back to the 
gateway server software 211, including the addressing information of the IP telephone 
241. (Step 1007) 

■'• - •' • 8; • ' The gateway server software 211 responds back to the gateway server 
software 11 1 that its part of the call has been successfully setup, and it forwards the 
address of its VoIP driver 1 14. (Step 1008) 

9. The gateway server software 1 1 1 configures its VoIP driver 1 14 with the 
address of the IP telephone 24 1, and the VoIP driver gets ready to start transmitting voice 
IP packets to that address. (Step 1009) 

FIG. 7A shows the call routing for a telephone call made between a PBX 
telephone 131 and an IP telephone 241, with the two telephones in different locales. 

FIG. 7B shows the call setup sequence for a telephone call made from an IP 
telephone 241 to a PBX telephone 131, with the two telephones in different locales. 

I . A user of the IP telephone 241 dials, and the IP telephone 24 1 sends a call 
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setup request to the IP/PBX call manager 240. (Step 1101) 

2. The IP/PBX call manager 240 receives the call setup request and forwards 
it to the gateway server software 211. (Step 1 1 02) 

3. The gateway server software 211 checks its database and finds thatthe user 
being dialed has a PBX telephone 13 1 managed by another gateway network 110. The 
gateway server software 2 1 1 connects to gateway server software 1 1 1 in the other gateway 
network via rhe WAN 101 . (Step 1 103) 

4. The gateway server software 111 sends a call setup request to the 
station/trunk driver 113. (Step 1 104) 

5. . The station/trunk driver 1 13 forwards the call setup request to the PBX 
130. (Step 1105) 

6. The PBX 130 calls the PBX telephone 131 of the called party. (Step 1106) 

7. The gateway server software 1 1 1 configures its VoIP driver 1 14 with the ' 
address of the IP telephone 24 1 , and the VoIP driver gets ready to start transmitting voice 
IP packets to that address. (Step 1 107) 

8. The gateway server software 1 1 1 responds back to the gateway server 
software 211 that its part of the call has been successfully setup, and' it forwards the 
address of its VoIP driver 1 14. (Step 11 08) 

9. The gateway server software 2 1.1 forwards the address of its VoIP driver 
214' to the IP/PBX call manager 240. (Step 1 109) 

...........10.. -.The JP/PBX. -call, manager 240 responds to the IP- telephone 241, 

forwarding it the address of the VoIP'driver 214. The IP telephone 241 then configures 
itself to begin routing IP voice packets to the VoIP driver. (Step 1110) 

FIG. 7C shows the call setup sequence for a telephone call made from a PBX 
telephone 13 1 to an IP telephone 241, with the two telephones in different locales. 

1 . A user of the PBX telephone 1 3 1 dials and sends a call setup request to the 
PBX 130. (Step 1201) ' 

2. The PBX 130 routes the call to the station/trunk driver 1 13. (Step 1202) 

3. The station/trunk driver 1 13 routes the call setup request to the gateway 
server software 111. (Step 1 203) 

4 . . The gateway server software 1 1 1 checks its database and finds that the user 
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being dialed has an LP telephone 241 managed by another gateway network 210. The 
gateway server software 1 1 1 connects to gateway server software 2 1 1 in the other gateway 
network via the WAN 101 . (Step 1204) 

5 . The gateway server software 2 1 1 checks its database and finds that the user • 
5 being dialed has an IP telephone managed by the IP/PBX call manager 240. The gateway 
server software 2 1 1 routes the call setup request to the IP/PBX call manager 240, and it 
attaches to the request the addressing information of its VoIP driver 214, since the 
gateway server software 21 1 determines that the voice stream will need to be routed via 

that driver. (Step 1205) 
10 6. The IP/PBX call manager 240 responds to the IP telephone 241, 

forwarding it the address of the VoIP driver 214: the IP telephone 241 then configures 
itself to begin routing IP voice packets to the VoIP driver 1 14. (Step 1206) 

7. The IP/PBX call manager 240 sends an acknowledgment back to the 
gateway server software 211, including the addressing information of the IP telephone 

15 241. (Step 1207) 

8. The gateway server software 21 1 responds, back to the gateway server 
software 111 that its part of the call has been successfully setup, and it forwards the 
address of its VoIP driver 114; (Step 1208) 

9 . The gateway server software 1 1 1 confi gures its VoIP driver 1 1 4 with the 
20 address of the IP telephone 24 1 , and the VoIP driver gets ready to start transmitting voice 

IP packets to that address. (Step 1209) 

FIG. 8 A shows the call, routing for a telephone call made between one IP 
telephone 141 and another IP telephone 241, with the two telephones in different locales. 
FIG. 8B shows the call setup sequence for a telephone call made from one IP 
25 telephone 141 to another IP telephone 241, with the two telephones in different locales. 

1 . A user of thelP telephone 241 dials, and the IP telephone 241 sends a call 
setup request to the IP/PBX call manager 240. (Step i 1301) 

2 The IP/PBX call manager 240 receives the call setup request and forwards 
it to the gateway server software 211. (Step 1302) 
, 30 ' 3 . The gateway server software 2 1 1 checks its database and finds that the user 

being dialed has an IP telephone 141 managed by another gateway network 110. The 
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gateway server software 2 1 1 connects to gateway server software 1 1 1 in the other gateway 
network via the WAN 101. (Step 1303) 

4. The gateway server software 1 1 1 sends a call setup request to the IP/PBX 
. call manager 140. (Step 1304) 
5 " ' 5. The IP/PBX call manager 140 forwards the call setup request to the IP 
telephone 141. (Step 1305) 

6. The gateway server software 1 1 1 responds back to the gateway server 
software 211 that its part of the call has been successfully setup, and it forwards the 
address of its VoIP driver 1 14. (Step 1306) 
1 0 7. The gateway server software 2 1 1 forwards the address of its VoIP driver 

214 to the IP/PBX call manager 240. (Step 1307) 

8. The IP/PBX call manager 240 responds to the IP telephone 241, 
forwarding it the address of the VoIP driver 214. The IP telephone 241 then configures 
itself to begin routing IP voice packets to the VoIP driver. (Step 1308) 

Features 

In this section we discuss the various features that can be provided features to 
users of IP telephones 141,241, coupled to the IP/PBX telephone system 33 in accordance 
with an embodiment of the present invention. Many of these features are also described 
20 in co-pending, commonly assigned U.S. patent application number 09/06 1 ,802, which is 

incorporated herein by reference. . r . . _ 

Automated Call Control Features 

Quality of Service Monitoring 

As discussed in co-pending, commonly assigned U.S. patent application number 
25 09/061,802, which is incorporated herein by reference, there are quality of service 
indicators which are placed in the IP voice packets at the time when the packets are 
generated in preparation for routing onto the LAN. At the later point in the call path 
routing, when the data in the IP packets are extracted and decoded, the quality of service 
indicators are assessed to determine if a reasonable quality for the voice conversation is 
30 being maintained. In U.S. patent application number 09/061,802, the VoIP call routing 
paths and the voice IP packets are generated/encoded by the VoIP driver 1 14 in one 
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gateway server 1 1 0 and extracted/decoded by the VoIP driver in another gateway server 
120.. 

With the introduction of the IP/PBX telephone system 33, the quality of service 
(QoS) determination may involve two separate legs of the IP network. For example, 
5 consider the call path shown in FIG. 9A; the voice IP packets that are generated at the IP 
telephone 241 are de-packetized/decoded at the VoIP driver 1 14. Thus, it is important 
that the multiple vendors agree on the required QoS threshold. Assuming that both the 
VoIP driver vendor and the IP telephone vendor agree on how to use QoS, then an 
assessment must be made as to where in the call path the quality degradation is taking 
1 0 place. If it is determined that the degradation is occurring on the WAN IP Network 101, 
(as opposed to on the LAN), then the communication stream currently using the WAN IP 
Network can be moved out onto the PSTN 102,' fallback to PSTN, as is described below 
and in U.S. patent application number 09/061,802, which is incorporated herein by 
reference. 

1 5 in order to detect a problem of the WAN, the VoIP driver 1 1 4 of the invention 

continues to monitor QoS for the entire path segment over which voice IP packets travel. 
For example, referring to FIG. 9A, the VoIP driver 1 14 monitors the QoS of packets 
generated at IP telephone 241.. If the QoS for this entire segment degrades to a given 
threshold, the VoIP driver communicates this to the gateway server software 111. The 

20 gateway server software 1 1 1 then initiates a secondary simple test of the QoS between the 
two gateway servers (the gateway server 210 of the caller and the gateway server 110 of 
the called party). This secondary test may involve sending bursts of IP packets over the 
WAN IP network 10 1 and having the VoIP drivers 1 14 and 214 on either end assess the 
QoS. Alternatively the test may be more simplistic, such as issuing a series of "ping" 

25 commands across the WAN IP network 101, between the two gateway servers 1 1 0 and 
210. If the secondary QoS test indicates performance degradation on the WAN 101 , then 
fallback to PSTN is initiated. If the secondary QoS indicates no degradation, then the 
problem is on the LAN. In this case there is little that the gateway server can do to 
alleviate said problem, other than alarm to an external system, such as a network 

30 management system. Such an alarm,.in more sophisticated network configurations, could 
activate load-balancing algorithms which might eliminate high-load network activities or 
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users. 

Fallback to PSTN 

Five different methods for the fallback to PSTN are discussed in co-pending, 
5 commonly assigned U.S. patent application number 09/061,802, which is incorporated 
herein by reference, page 44 line 1 through page 49 line 31. The differences between the 
methods are related primarily to the variations in PBX configurations. In considering how 
. a fallback would be enacted in a VoIP call routing path involving an IP telephone, 
reference FIG. 9A. The methods in U.S. patent application number 09/061,802, are the 
1 0 same when applied to the PBX telephone user at one end of the call. For the IP telephone 
' user at the other end of the call, some additional method must be described. 

Consider that FIG. 9A illustrates an original VoIP call involving an IP telephone 
241, and that FIG. 9B illustrates the modified call path once the fallback to PSTN 
operation has been completed. The path of the call now flows from PBX telephone 13 1 
15 at a first location through the PBX 130; loops through the station/trunk driver 1 13 and 
back into the PBX 1 30 (using a second port in the PBX 1 30) and out into the PSTN 1 02. 
The PSTN 102 at the second, site feeds the call into PBX 230 and then into station/trunk 
driver 2 1 3, where it is routed through VoIP driver 2 1 4 and finally on to the IP telephone 
. 24.1. 

20 One way that the fallback to PSTN operation can be accomplished is as follows. 

-T'he sequence' of'events -starts when the VoIP driver 1 14. in gateway server 110 dete.cts 
QoS degradation on the call path (between VoIP driver 1 14 and IP telephone 214), and 
gateway server software 1 1 1 is notified of this issue. Next, gateway server software 1 1 1 
coordinates the execution of a secondary test by exchanging packets between its VoIP 

25 driver 1 14 and the VoIP driver 214 of the gateway server 210. This test again indicates 
serious degradation, so the gateway server software 1 1 1 initiates a fallback to PSTN. First 
it announces its intention via a notification sent to the caller gateway server software 211. 
The caller gateway server 210 then coordinates with the called gateway server 1 10 to 
setup a PSTN call between the two gateway servers 1 10 and 210 via the PBXs 130 and 

30 230. (Further details of this can be found in co-pending, commonly assigned U.S. patent 
application number 09/061 ,802, at page 46, line 24 through page 47, line 1 1) As soon 
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as 



the PSTN call is setup between the two gateway servers, the gateway server software 
21 1 must command the IP telephone 241, via its associated IP/PBX call manager 240, 
to start routing its packets to the local VoIP driver 214 instead of the remote VoIP driver 
1 14. The modified call path is now complete and the users' conversation can continue. 

Multi ple IP/PBX System Vendors Supported 

The invention supports more than one equipment vendor for the IP/PBX system 
33. For example, the vendor of the IP/PBX system 33 associated with one gateway 
network 20 may differ from the vendor of the IP/PBX system associated with another 
gateway network 30. To accomplish this both IP/PBX systems must support and be using 
the same kind of encoding andcompression algorithms and they must further support the 
same voice over IP protocol, for example H.323. 

Usability Features 

Direct Inward Dialing for TP Telephone Users 

The gateway server 31 of the present invention, with its tight integration to the 
PBX 30, and its ability to coordinate call setup with the IP/PBX call manager 40 of the 
IP/PBX telephone system 33, also provides a unique capability to support direct.inward 
dialing (DID) to the IP telephone users. Current IP/PBX telephone systems 33 support 
a direct inward dialing capability only via another specialized piece of equipment which 
must be separately purchased. A cheaper solution, made possible by the gateway server 
of the present invention, is to configure phantom PBX ports (not shown) on the PBX 30. 
A PSTN phone number is associated with a PBX phantom port for each IP telephone user, 
and (as the PBX 30 has already been configured to operate with the gateway server 20, 
30), all calls incoming from the PSTN 2 are routed from the phantom port to the gateway 
server 20, 30. The gateway server 20, 30, maintains the association of the PBX DID 
phone number to the IP telephone extension, and thus routes the call to the IP/PBX call 
manager 40 for processing, and the IP/PBX call manager in rums routes the call to the IP 
telephone. In the event that the IP/PBX call manager determines that the IP telephone 4 1 
is for some reason unavailable, i.e. the user may already be engaged in a telephone 
conversation, then the gateway server 20, 30 of the present invention further provides 
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Unified Voice-mail 

The current integration implementation of EP/PBX telephone systems with PBX 
telephone systems has a major drawback in that separate voice-mail systems are used for 
the IP telephone users and the PBX telephone users. For example, the users of the PBX 
telephones use the PBX-associated voice-mail. For PBX voice-mail* there are currently 
two major vendors, Octel and Audix, which have both been in the business for a long time 
and have quite matures products. For the IP-based voice-mail, there is less 
standardization, and the available products are less mature and do not scale as well as the 
PBX Voice-mail products do." Having two different voice-mail systems at the same 
company site creates problems for the users. For example, a user cannot forward voice- 
mail between the systems, and the voice-mail features and commands are likely to differ 
between the different systems. Furthermore, the multiple voice-mail systems require 
separate system administration for the each different voice-mail system. 

The invention solves this problem by allowing all users, including the IP/PBX 
telephone users, access to the fully scalable and mature PBX voice-mail system. The 
system of the invention canbe configured to automatically re-route to the PBX voice-mail 
if the IP/PBX telephone user does not pick up after a certain number of rings (such as 4 
or 5), or if the called party is otherwise unavailable. The method of implementation 
involves assigning each IP telephone user.a port.in the BBX telephone system.-.Since the. 
port is not physically connected with a telephone, it is termed a "phantom" port. 

FIG. 10A shows a sample call setup flow for a call attempt from a caller PBX 
telephone 130 to the called IP telephone 141, where the IP telephone 141 is found to be 
busy, and the call is thus routed to the called party's voice-mail system 125. Both caller 
and called parties are located at the same site and associated with the same gateway server* 

no: - -■«■•• 

1 . A user at the caller PBX telephone 1 3 1 dials to the called IP telephone 1 4 1 
user at the same company facility using the extension to dial. The call is routed to the 
PBX 130. (Step 1401) 

2. The PBX 1 30 finds that the called number corresponds to an extension it 
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manages, so it routes to that extension's port. The called party's port (actually a phantom 
port with no telephone attached) is configured to automatically forward all calls over to 
the gateway server 1 10, so the call is routed to the station/trunk driver 1 13. (Step 1402) 

3. . The station/trunk driver 1 13 routes the call setup request to the gateway 

server software 111. (Step 1403) 

4. The gateway server software 1 1 1 checks its database and finds that the user 
being dialed has an IP telephone 141 managed by the IP/PBX call manager 140. The 
gateway server software 1 1 1 routes the call setup request to the IP/PBX call manager 140, 
and it attaches to the request the addressing information of its VoIP driver 1 14, since the 
gateway server software 1 1 1 determines that the voice stream will need to be routed via 

that driver. (Step 1404) 

5. The IP/PBX call manager 1 40 finds that the particular IP telephone 1 4 1 is 
unavailable for use (for example, it may be busy, or a "do not disturb" setting may have 
been enabled by the user). The IP/PBX call manager 140 thus responds back to the 
gateway server software 1 1 1 that the called IP telephone 141 is unavailable, and thus the 

call cannot be handled. (Step 1405) 

6. The gateway server software 1 1 1 now decides to route the call to the voice- 
mail system, so it first commands the CTI driver 1 12 to reconfigure the PBX 1 30 sbmat 
the forwarding of the call on that port goes directly to voice-mail. (Step 1406) 

7. The CTI driver 112 commands the PBX 130 to reconfigure itself so mat 
the forwarding of the call on that port goes directly to voice-mail. (Step 1407) ...... 

8. ' The gateway server software 1 1 1 commands the station/trunk driver 1 1 3 
to route the call to the PBX 1 30. (Step 1 408) 

9. ■ "The station/trunk driver 1 13 routes the call to the PBX 130. (Step 1409) 

10. The PBX 130hasbeenconftguredwithaphantomPBXportforthecalled 
party. Since there is no physical telephone attached to that port, the call is routed directly 
to the voice-mail system 125. (Step 1410) 

1 1 . Meanwhile, the gateway server software 1 1 1 commands the CTI driver 1 1 2 
to have the PBX 130 re-configure the phantom port of the called party back to its original 
state, which is to forward calls to the gateway server software 111. (Step 141 1) 

12. The CTI driver 1 12 commands the PBX 130 to re-configure the phantom 
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port of the called party back to its original state. The PBX 130 performs the re- 
configuration, so it is now ready for the next incoming call for that extension. (Step 1412) 
FIG. 10B shows the completed call routing from the caller's PBX telephone to the 
called party's voice-mail. The voice routing is from the caller PBX telephone 131 
through the caller's PBX port in the PBX 130, loops through the station/trunk driver 1 13, 
back into the PBX 130, and finally into the voice-mail system 125 via the called party's 
PBX phantom port. 

The case for routing between different sites is somewhat more complex. FIG. 1 1A 
shows the completed routing of a call made by a PBX user at one site, through the VoIP 
network, to the voice-mail system of an IP telephone user at a remote site. In more detail, 
the voice routing is from the caller PBX telephone 131 through the caller's PBX port ifi 
the PBX 130, through the station/trunk driver 1 13 and the VoIP driver 1 14, through the 
WAN IP network 101 to the other site, through the VoIP driver 2 14 and the station/trunk 
driver 213, to the PBX 230, and finally into the voice-mail system 225 via the called 
party's PBX phantom port. 

FIG. I IB shows a call setup flow" corresponding to the voice path shown in FIG. 
1 1A. The caller at caller PBX telephone 131 makes a call to the called IP telephone 241, 
where the called IP telephone 241 is found to be unavailable, and the call is thus routed 
to the called party's voice-mail system 225. 

1. A user at the caller PBX telephone 131 dials to the called IP telephone 241 
user at a different <company.*facility using. an .on-net number to.dial. The call is routed to 
the PBX 130. (Step 1501) 

2. The PBX 130 routes the call to the station/trunk driver 1 13. (Step 1502) 

3. The station/trunk driver 113 routes the call setup request to the gateway 
server software 111. (Step 1 503) 

4. The gateway server software 1 1 1 checks its database and finds that the user 
being dialed is located at another company facility, under the purview of the gateway 
server 210. The gateway server software 11 1 forwards the call setup request to the 
gateway server software 21 1 via the WAN IP network 101. (Step 1504) 

5. The gateway server software 21 1 checks its database and finds that the user 
being dialed has an IP telephone managed by the IP/PBX call manager 240. The gateway 
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server software 2 1 1 routes the call setup request to the IP/PBX call manager 240, and it 
attaches to the request the addressing information of the VoIP driver 114, since the 
gateway server software 2 1 1 determines that the voice stream will need to be routed via 
that driver (assuming the called party is available for the call). (Step 1505) 
5 6. The IP/PBX call manager 240 finds that the particular IP telephone 241 is 

currently unavailable, and thus responds back to the gateway server software 21 1 that the 
called IP telephone 241 is busy, and thus the call cannot be handled. (Step 1506) 

7. The gateway server software 2 1 1 now decides to route the call to the voice- 
mail system 225, so it first commands the CTI driver 2 12 to reconfigure the PBX 230 so 

1 0 that the forwarding of the call on that port goes directly to voice-mail. (Step 1 507) 

8. ' The' CTI driver 2 12 commands the PBX 230 to reconfigure itself so that 
the forwarding of the call on that port goes directly to voice-mail. (Step 1508) 

9. The gateway server software 2 1 1 commands the station/trunk driver 213 
to route the call to the PBX 230. (Step 1509) 

1 5 io. The station/trunk driver 213 routes the call to the PBX 230. (Step 1510) 

1 1 . The PBX 230 has been configured with a phantom PBX port for the called 
party. Since there is no physical telephone attached to that port, the call is routed directly 
to the voice-mail system 225. 

12. The gateway server software 2 1 1 configures its VoIP driver 214 to begin 
20 routing voice packets to the address of VoIP driver 114. (Step 1512) 

13. The gateway server software 211 responds back to the gateway .server 
software 1 1 1 with the addressing information of the VoIP driver 214. (Step 1513) 

14. The gateway server software 1 1 1 configures its VoIP driver 1 14 to begin 
routing voice packets to the address of VoIP driver 2 1-4. (Step 1 514) 

25 15. The gateway server software 1 1 1 configures its station/trunk driver 1 1 3 to . 

route the call over to the VoIP driver 1 14. The call routing is now complete. (Step 1551) 
1 6 . Meanwhile, the gateway server software 2 1 1 commands the CTI driver 2 1 2 

to have the PBX 230 re-configure the phantom port of the called party back to its original 

state, which is to forward calls to the gateway server software 21 1. (Step 1516) 
30 17. The CTI driver 212 commands the PBX 230 to re-configure the phantom 

port of the called party back to its original state. The PBX 230 performs the re- 
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configuration, so it is now ready for the next incoming call for that extension. (Step 1517) 

. L FIG. 12 shows how the gateway server 1 10 polls the voice-mail system 125 at • 
regular intervals (the interval being configurable) in order to be able to keep the IP 
5- telephone users' telephones current with regard to whether the voice-mail light on the 
phone is on or off. 

1 . The gateway server software 1 1 1 makes a request to the CTI driver 1 1 2 to ■ 
request the status of the voice-mail for a particular user. (Step 1 601) 

2. The CTI driver 1 1 2 passes on the voice-mail status request to the PBX 1 30. 
' 10 (Step 1602) 

3. The PBX' 130 commands the voice-mail server 125 to return the 
information of whether said user has voice-mail in the voice mailbox. (Step 1603) 

4. The voice-mail server 125 responds to the PBX 130 with a yes/no status. 
(Step 1604) 

15 5. The PBX 130 routes the status response back to the CTI driver 1 12. (Step 

1605) 

6. The CTI driver 1 1 2 routes the status response to the original requestor of 
the status, the gateway server software 1 1 1. (Step 1606) 

7. The gateway server software 1 1 1 maintains the state voice-mail status for 
20 each voice-mail-enabled IP telephone user. It now checks its database to see if the new 

* status* represents a-change-from-the-prev.io.us status. . If there is no change ? .the next two 
steps are not executed. If there is a change, the gateway server software 1 1 1 logs the 
change into its database and forwards the status update to the IP/PBX call manager 140. 
(Step 1607) 

25 8. The IP/PBX call manager 1 40 commands the IP telephone to turn its voice- 

mail indicator light to either ON or OFF, depending on the received status. (Step 1 608) 
Unified Dialing Plan 

The discussion of numbering plans described in co-pending, commonly assigned 
U.S. patent application number 09/061,802, which is incorporated herein by reference, 
30 page 33, line 14 to page 35, line 31 apply equally to the embodiment of the invention 
which includes an IP telephone network. For example, a UNP (unified numbering plan) 
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or an ETN (enterprise telephone number) scheme can be implemented using the voice 
gateway system of the invention coupled with the IP telephone system. 

A configuration where some users in a network are equipped with IP telephones 
as their primary telephones, while others have PBX telephones, can be handled seamlessly 
by the gateway server invention. The dialing plan can be coordinated such that both PBX 
telephone' users and IP telephone users at the same site can have the same location ID, 
with possibly different extension ranges. At a site, any user (PBX or IP telephone) can 
call any other user (PBX or IP telephone) using the extension only to dial. Users at other 
enterprise sites make calls to both kinds of telephones, dialing 8 + location ID + extension 
(in an ETN scheme), and the callers are not required to know which kind of telephone a 

particular user has. " ' '*V'' 

Alternatively, if some or all of the IP telephone users are at a small branch site, the 
telephones at the branch site may be configured with a different location ID. The 
invention could then be configured such that users atthe main site would be able to dial 
either 8 + location ID + extension or simply an extension. Having either scheme available 
might be a good transition for an enterprise that is moving toward the more flexible and 

easy to manage ETN type plan. 

The invention implements the dialing plan within the gateway server. 

In one embodiment of the invention, all calls made by IP telephone users to other 
IP telephone users in the same IP/PBX telephone system are handled completely within 
the IP/PBX telephone system coordinated by the IP/PBX call manager, while all other 
calls are routed to the gateway server for interpretation or translation. Existing IP/PBX 
telephone systems are generally designed to follow such a scheme, where dialing IP 
telephone to IP telephone is handled within the IP/PBX telephone system by the IP/PBX 
call manager (refer to FIG. 2), and such systems typically support different variations for 
how other calls are handled. In fact, the lack of a standard way to handle calls to non-IP 
telephones calling out can create difficulties and complexity for the network administrator 
when integrating an IP telephone system (or multiple IP telephone systems) into the 
existing telephone system. Use of the invention makes this easier, since the dialing plan 
for the entire enterprise is coordinated in one place, in the gateway server. 

In another embodiment of the invention, all calls made by IP telephone users are 
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routed by the IP/PBX call manager directory into the gateway server for interpretation or 
translation. This preferred embodiment of the invention has the same advantages as the 
previously described embodiment, and furthermore has additional integration advantages, 
including the ability to have a complete and unified call log, and the- ability to have a 
consistent caller ID format across the enterprise. If not every call goes to the gateway 
server, then the logging done by the gateway server will be missing some calls, which 
renders the call log data less useful. Similarly, if the caller ID information is always 
inserted or appended into the call setup request, as is possible with this preferred 
embodiment, then the format of the caller ID information as well as the actual caller ID 
data can be maintained in a single central location. The alternative (as would be required 

in the previously described embodiment) would be to maintain caller ID format in the 

a 

both the call managerand the centralized gateway server, and to maintain the IP telephone 
user directory information in both the call manager and in the enterprise directory. 
Caller ID 

As described in co-pending, commonly assigned U.S. patent application number 
09/061,802, which is incorporated herein by reference, the integration of the gateway 
server with an enterprise directory provides a central repository, for modifying user 
information. User information includes many different attributes describing the particular 
user, including name and office extension number for the user; (refer to "Table 9; White 
Pages" in co-pending, commonly assigned U.S. patent application number 09/061,802, 

4 

which is incorporated-herein by reference,, whiph.s.h.ows attributes . of user records ,within 
the directory). Additional attributes are added to support the additional user information 
required to be maintained regarding a user's IP telephone. Table 1 shows a set of 
additional attributes that are used to support the IP/PBX telephone system's inclusion in 
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the gateway server's network. 



Attribute 



Primary Phone Type 
IP/PBX Call Manager- 



Address 



Description 



One of "PBX". "Mobile", or "IP" 

Addressing information of the IP/PBX call manager 

associated with the IP telephone. 

Addressing information required by the IP telephone 

system to uniquely identify the IP telephone; this may be 

the IP address or other proprietary type of address. 



Office IP Phone 
Address 



IP Phone IP Address 



IP address of the user's pri mary IP telephone. 



Table 1 : New White Pages Attributes for Extended Invention 

On Calls Incoming to TP Telephones " " 

Since, (in the preferred embodiment of the invention), the call setup for all calls 
made to the IP telephones is done under the coordination of the gateway server software, 
which accesses the enterprise directory, the caller ID and name display information are 
always added to the incoming call setup request, which flows from the.gateway server to 
the IP/PBX call manager to the IP telephone, where it is shown on the IP telephone 
display. 

On Calls Ou t going from TP Telephones 

Outgoing calls from the IP telephone can support the caller ID, as long as the call 
is routed to "the gateway server, which can then look up the caller ID information in its 
database and forward it to the called parry, and the information can thus be displayed as 
described in the invention of co-pending, commonly assigned U.S. patent application 
number 09/061 ,802, which is incorporated herein by reference. 
At Browser Application. Incom ing Calls 

Calls which are routed through to either IP telephones or mobile telephones are 
routed through the gateway server. The gateway server has the knowledge as to which 
users currently are logged in to the gateway server via the browser GUI interface on the 
users' PCs. If a browser interface is up for the given user, the gateway server will cause 
the browser GUI to display the caller ID and name display information for the call as part 
of a pop-up dialog window. 
Common Caller TP Format 
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A unique advantage of the approach described, for always relying on the caller ED 
and name information to be inserted by the voice gateway invention, is that a common 
format for the identification information can be maintained across several different 
departments and phone systems of an enterprise. 
Call Control Features Available at IP Telephone 

Since the IP telephone should be a convenient alternative to having a PBX 
telephone, the same call control features generally available to the PBX telephone user 
should also be available to the IP telephone user; 
Hold/Retrieve 

If the IP/PBX telephone system supports it, a second call can be routed to the user 
while a call is already in.progress. The second call may be signaled to the IP telephone 
user by another ring or by a special tone played over the incoming voice, and the caller 
ID for the new caller may be shown on the display of the IP telephone. If the IP telephone 
user wishes to, he may verbally ask the original caller to hang on, and then dial a 
sequence, such as "*5" to put the first caller on hold and answer the new caller. 
Subsequently, the IP telephone user may dial another sequence, such as "*6" to retrieve . 
the original and resume that conversation. 
Transfer 

The transfer of a call from the called party using an IP telephone to another caller 
in the enterprise can be accomplished by the invention under coordination of the gateway 
server.- GonsiderFIG.-l3 A and«i2B.-FIG. .13A shows- a- call inprogress from a caller on 
a PBX telephone 131 to a called party using an IP telephone 141 in the network of the 
same gateway server. FIG. 13B shows the end result ofthe IP telephone 141 user'saction 
to transfer the call to another user at IP telephone 24 1 within the enterprise, In this case 
the second called user is located at another site, and thus the resulting routing is 
accomplished via the IP network 101. 

"Xn example of the steps describing how the transfer ofthe call is accomplished 
by the system are shown in FIG. 13C and described in the following sequence of steps: 

1 . During a conversation with the caller at PBX telephone 1 3 1 , the called user 
at IP telephone 141 determines that the caller should be transferred to speak with a.third 
party at IP telephone 241 at another site. So .the caller keys a special sequence, such as 
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-3" followedby the location ID and extension of the thirdparty (on-net dialing), and the 
transfer request is passed on to the IP/PBX call manager 140. (Step 1701) 

2. The key sequence is interpreted by the IP/PBX call manager 140 winch 

forwards the transfer request to the gateway server software 111. (Step 1 702) 

3 Thegatewayserversoftwarelllforwardsthetransfersetuprequesttothe 

remote gateway server software 21 1 with the gl ven location ID defined in the dialed digits 

and the extension. (Step 1703) 

4 The remote gateway serve, software 211 cheek? its database and 
determines that the called party is in its gateway network, and on an IP telephone. The 
remote gateway server software 211 makes a eall setup request to the HVPBX call 
manager 240, and passes also toe address of the VoIP drrver 114 of the gateway server 
110. (Step 1704) 

5 The IP/PBX call manager 240 issues a call setup request to the IP 
telephone 241 , which in rums rings the telephone and configures itself to begin shipping 
voice packets back to the VoIP driver 1 14. (Step 1705) 

6 The IP/PBX call manager 240 responds back to the gateway server 
software211and includes the addressing infonnation for IP telephone 241. (Step 1706) 

7 The remote eateway server software21 1 sends a response backto the local 
gateway server software 1 1 1 with the address of the IP telephone 241. (Step 1707) 

' 8 . The gateway servet software 1 1 1 commands its VoIP driver 1 14 to start 

routine the voice packets to the IP telephone 241. (Step 1708) - 

" 9. The gateway server software 1 1 1 messages tothe IP/PBX call manager 140 
that it can take down its leg of the call. (Step 1709) 

10 The IP/PBX call manager 140 relays this infonnation to the IP telephone 
" 141, and the user at this telephone now knows that the transfer has completed OK. (Step 
1710) 

Forwarding 

Call forwarding is handled by the gateway server as is discussed in co-pend,ng, 
commonly assigned U.S. paten, application nomber 09/061,802, wh.ch is incorporated 
herein by reference. The model is easily extended ,0 handle the IP telephones. As an 
example, conside, a use, who has his "follow-me" conf,gu,=d to route caUs tat tohts IP 
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telephone, and secondly to a secretary's desk. An incoming call is routed by the gateway 
server to the IP/PBX call manager, and in rum to the IP telephone. If after several rings 
the IP telephone user doesn't answer, the IP/PBX call manager stops the ringing and 
routes a negative acknowledgment back to the .gateway server. The gateway server 
receives the acknowledgment and then routes the call via PBX to the secretary's desk 
telephone. 
Conferencing 

Call conferencing is also coordinated through the gateway server. If both the 
IP/PBX telephone system and the PBX telephone system support conference calling, then 
conferencing of multiple callers can be supported. FIG. 14 shows an example of a 3-way 
conference call in progress. 'The first caller at the PBX telephone 131 has called a'co- 
worker at an IP telephone 141 (the second party). After their call was established, a third 
party, calling from an IP telephone 241 at a remote office, joins the conversation. In the 
implementation shown, there are three call paths setup. In the integrated system shown, 
each of PBX telephone 131, IP telephone 141, and IP telephone 241 have the capability 
to combine the two incoming voice streams as needed, or select the stream with voice on 
it and provide that- to the user. At the PBX telephone 131, the CTI driver 1 12 may be 
working with the PBX 130 to implement the conferencing, for example, selecting the 
higher volume of the two incoming voices and patching that voice to the first party. With 
the gateway server invention, the usage protocol for conferencing can be offered in the 
.same way for the different kinds of telephone users.-- 

An alternative implementation of conferences involves the use of a Multipoint 
Conference Unit (MCU) such as that defined by the ITU H.323 standard recommendation. 
Call Control At Browser Application 

Call control features can also be offered, to the IP telephone user who is logged 
into the internal network and running the browser application that provides a call control 
interface to the gateway server. The IP telephone may be the user's primary telephone, 
and for convenience, the user may want to control the telephone's features through the 
browser GUI on the user's personal computer. (Refer to co-pending, commonly assigned 
U.S. patent application number 09/061,802, which is incorporated herein by reference for 
a detailed description.) - 
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Refer to FIG. 15, and consider the eiamp.e of a user clicking on the "Dial" button 
on the PC's browser-based GUI in order to make a cal. from his IP telephone to another 
usefs PBX telephone. This call setup sequence results in the same call routing path as 
m shown already m FIG.4A. Theca.. selup sequence is defined with me followmg 
steps which are also shown graphically in FIG, 1 5 : 

, The user of the.PCs browser-based GUI 142 clicks on the "Dtal burton. 
The software notifies the web server of the gateway server software ,11 of this eve... 

(S,CP ' T The gateway server software 1 1 1 sends a notification to the IP/PBX call 
n^r ,40 tha, a user associated with one of its IP telephones has J« issued a call 
setup request, and it forwards the VoIP driver 1 ,4 address with the request- (Step ISO.) 

3 The IP/PBX call manager 140 forwards the requesr to dta! to the 

appropriate IP telephone 14. . The IP telephone 14, men initiates the dialing sequence 
andp.aystheapptopriatefeedbacktonesfortheusetto.hear.andconfiguresitself.obegm 

transmitting IP voice packets to the VoIP driver 114. (Step 1803) 

4 The IP/PBX call manager 140 responds back to the gateway server 
software 1 1 1 with an indication that fire call is progressing successfully. (Step 1 804) 

5 The eateway server software 1 1 1 checks its database and finds the called 
pstty has aPBXteJphone 13,, so i, sends a caU setupreques, to the suoon/tnmk dnver 

113. (Step 1805) . pRY 

6 . The stauon/trunk driver 1 13 forwards the call setup request to the PBX 

130. (Step 1806) 



7 ThePBX 130calls the PBX telephone 131 of the called parry. (Step 1807) 
8. 



0 The gatewav server software 1 1 1 configures its VoIP driver with the 
address of the IP telephone 141 , and the VoIP driver gets ready to start transmitting voice 
IP packets to that address. (Step 1808) , » A . 

9 The gateway server software 1 1 1 sends an acknowledgment back. to. the 
br o W ser-basedGUn42,soitcanprov 1 dead 1S pla y updatew 1 thfeedbacktotheGUIuse, 

(Step 1809) . ., , , 

Most of the other major can control functions are handled stmt.arly, by .b 
gatewayservercoordinatingwiththelP/PBXcaUmanager.andupdatingutehrowserGU, 
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at the completion of the operation. The call control functions handled in this manner 
include dial, answer, hold/retrieve, hang up,- transfer, and conferencing. It is important 
to note that the IP/PBX telephone system must support this functionality in order to 
provide such call control from the PC. 

The "do not disturb" and forwarding functions are handled simply by the browser 
messaging the request to the gateway server. Since' both these actions are simply state 
changes that will affect future calls, the gateway server notes this information in its 
database and will use it to make routing decisions when incoming calls arrive for the user. 
Destination Busv Handling At Browser Application 

Destination Busy handling features with browser-based GUI control for IP 
'telephones can be handled in an equivalent way to what has been described in co-pending, 
commonly assigned U.S. patent application number 09/061,802, which is incorporated 
herein by reference, for PBX telephones. Refer to co-pending, commonly assigned U.S. 
patent application number 09/061,802, which is incorporated herein by reference, page 
65 line 1 to page 69 line 18. 

In the case where the originator of the call is on an IP telephone and the caller is 
using the PC browser application, and a busy signal is reached at the called party (say the 
called party is on a PBX telephone), the caller is provided with several options by the 
GUI, including (as described in co-pending, commonly assigned U.S. patent application 
number 09/061,802, which is incorporated herein by reference) "send alert", "request 
callback", "ring. thrqugh' 1 ,, and "cancel cair(equiyaLent to hanging up). 

Each of the options is handled the same way as in co-pending, commonly assigned 
U.S. patent application number 09/061,802, which is incorporated herein by reference, 
except that the "ring through" option to voice-mail is implemented in a slightly different 
way, since the voice-mail for the IP telephones is associated with a PBX; this has already 
been discussed earlier in the description. 
^ PhoheTHVectorv At Browser Application 

For IP telephone users, the "white pages" telephone directory associated with the 
browser can be used for convenience when dialing to other users, or when transferring a 
call. Refer to co-pending, commonly assigned U.S. patent application number 
09/061,802, which is incorporated .herein by reference, for a detailed discussion. 
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rail Log 

The call log is described in co-pending, commonly assigned U.S. patent 
application number 09/06 1 ,802, which is incorporated herein by reference, page 64, lines 
10 to 23. 

The logging of calls to and from IP telephones follows a similar flow. It is cntical 
that the gateway server know when a call is being setup, and when a call is terminated, 
and also when a call changes state (such as when a call is transferred, for example). By 
considering the call setup flows for setup of IP telephone calls described previously, * is 
clear that the gateway server has the knowledge of when calls are initially setup, and thus 
. can write the needed log information for the call initiation event. On the other hand, it is 
not so obvious that the gateway server would be aware of call termination events. For 
example, consider the case of an IP-to-IP telephone call as shown in FIG. 5A. A call 
could be handled entirely within the IP/PBX telephone system. In order for the call log 
to operate seamlessly regardless of the kind of telephone the various users are operating, 
the software object that first discovers that the termination has occurred must send out a 
notification to its controller (i.e! IP/PBX call manager in the case of an IP telephone) 
which the controller must in turn route to the gateway server. 
Follow Me Control 

At Browse r Application 

As described in co-pending, commonly assigned U.S. patent application number 
09/061,802, which is incorporated herein by reference, there are several options for call 
control. Those discussed relevant to PBX telephones are also relevant to IP telephones. 
Given that the invention can now coordinate multiple types of telephone systems, pan of 
the data stored for each user will include which telephone is the primary telephone for the 
user. The primary telephone might be the PBX office telephone (the default), or a mobile 
telephone, or an IP telephone. Which telephone is the primary would be entered into the 
gateway server database by a system administrator. This knowledge of the user's primary 
telephone tvpe is used for "follow-me" routing. The default routing of any incoming call 
for an enterprise user will always be to route it to the primary telephone; if primary 
. telephone is not answered, the default secondary routing is to voice-mail. However, there 
are several ways that more flexible routing can be enabled. 
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Firstly, users could be given access to modify their "default" routing via the 
browser interface. For example, if a user's default was (1) IP telephone, and (2) voice- 
mail, the user might modify to (1)EP telephone, (2) mobile telephone, and (3) voice-mail. 

Alternatively, only a system administrator might be given the option to modify the 
user's default routing, 

Filters can also be stacked one upon the other. For example, a user might have a certain 

- filter applied all the time, such as the following: 

Filter ALWAYS_AVOID 

If caller is "ex-husband" then 
Route to voice-mail. 

- i ^ .... -..-t End if r • 

Smart Filters for F611ow-Me Scheduling 

Users may be given the ability to setup filters on how to route their calls at certain 
times of the day. For example, the user may want to route directly to voice-mail during 
nights and weekend times. This can be accomplished by building call filters. A user can 
build up a set of favorite call filters and apply these at different times of the day. For 
example, a software engineer user may want to take only particular calls during the 7:00 
to 9:00 a.m.. time frame to guarantee uninterrupted work time. A filter such as the 
following could be constructed by the user, using simple point-and-click methods on the 
browser-based GUI: 

Filter UNINTERJIUPTED^WORK^TIME. , . ,,. v 

If caller is one of the following: ("Spouse' 1 , "Boss", "Child's School") then 

Route to Primary Office telephone, then Voice-mail, 
Else if caller is ("Customer X") . 
Route to "Joe Green" 

Else 

• 1 1 .■• *.">« -Route-to Voice-mail" 
End 

This filter could then be applied to the hours of 7:00 to 9:00 a.m. in the user's 
calendar. 

Integrate d OA&M (Operations. Administration, and Maintenance) 
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inventionprovidesacommonbrowserbasedmterface,by w 
can be managed from a single point. 

I2S ^ n3£ ^ : f the most common administrative functions which is 

User management is one of the most commo 

-«° ftafor ™* nieSard ::Zt— -Used OU, add . new 
For example, an adn— r could, torn *^ dfteW— ^ 

P re vious felephone systems have not been intend - to -y J ' ^ 

specifying the IP address, another 0 A&M monitor for setting up the IP 
and so on. 

MMimnZ*!^^ c , ncludine SNMP. Alarms from 

Theinventionsuppottsopenstandardsforalarms^ncludmgSNMP. 

nmmerciallv available network management system, or 

r=r:=: — r: -— ... 

It is to be understood that even though numerous charactenst.cs and ad . 
d«scrfpdon,,o S e,h^^ 

of rnc invention, to disclosure is iilusrrativc on, d ch n y ^ ^ 

in which the appended claims are expressed. 
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What is claimed is: 

1. In an IP/PBX telephone system (33) coupled via a gateway server (3 1) to a PBX 
(12) having a voice-mail system (125) and a plurality of unused, phantom ports, gateway 
server software (111) comprising: 

means for configuring at least one of the phantom ports on the PBX ( 1 2) 
to forward calls directed to the phantom port to an IP telephone (41) via the gateway 
server (31); 

means for receiving a call set up request for a call directed to the phantom 

port; 

. ■ ... — means for forwarding the call setup request to the gateway server software 
(1 1 1) in the gateway server (31); 

means for forwarding the call set up request from the gateway server 
software (1 1 1 ) to an IP/PBX call manager (40) in the IP/PBX telephone system (33); 

means for determining that the IP telephone (4 1) is unavailable using the 
IP/PBX call manager (40); 

means for reconfiguring the phantom port on the PBX (1 2) to forward calls 
to the voice-mail system (125); and • ■ 

means for forwarding the call to the voice-mail system (125). 

2. A system .accprdin&to claim I , wherein the gateway server (3 1 ) comprises a CTI 
driver (1 15) and wherein the means for reconfiguring the phantom port on the PBX (12) 
comprises the gateway server software (1 1 1 ) having means for instructing the CTI driver 
(115) to direct the PBX (12) to reconfigure the phantom port. 

3. A system according to claim 1 , wherein the means for forwarding the call set up 
■ request- from the gateway server software (1 1 l)toan IP/PBX call manager (40) comprises 

means for attaching to the call set up request addressing information of a VoIP driver 
(114) in the gateway server (31). 
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A system according to claim .1 , wherein the gateway server software (111) further 
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comprises means for restoring the configuration of the phantom port on the PBX (12) to 
forward calls directed to the phantom port to the IP telephone (41). 

5. - . Amethodofprovidingvoice-mailtoanIPtelephone(41)onanIP/PBXtele P hone 
system (33), the IP/PBX telephone system (33) coupled via a gateway server (31) to a 
PBX ( 1 2) having a voice-mail system ( 1 25) and a plurality of unused, phantom ports, the 

method comprising steps of: 

configuring at least one of the phantom ports on the PBX ( 12) to forward 
calls directed to the phantom port to an IP telephone (41) via the gateway server (3 1); 

receiving a call set up request for a call directed to the phantom port; 

forwarding the call set up request to gateway server software ( 1 1 1 ) in the 

gateway server (31);' 

forwarding the call set up request from the gateway server software (111) 

to an IP/PBX call manager (40) in the IP/PBX telephone system (33); 

determiningthattheIPtelephone(41)isunavailableusingtheIP/PBXcall 

manager (40); 

reconfiguring the phantom port on the PBX (12) to forward calls to the 

voice-mail system (125); and 

forwarding the call to the voice mail. system. 

6. A method according to claim 5, wherein the step of reconfiguring the phantom 
port on the PBX (12) is accomplished using the gateway server software (111). 

7. A method according to claim 6, wherein the gateway server (3 1 ) comprises a CT1 
driver (1 15) and wherein the step of reconfiguring the phantom port- on the PBX (12) 
comprises the step of the gateway seiver software (111) instructing the CTI driver (115) 
to direct the PBX ( 12) to reconfigure the phantom port. 

8. A method according to claim 5, wherein the step of forwarding the call set up 
request from the gateway server software ( 1 1 1 ) to an IP/PBX call manager (40) comprises 
the step of attaching to the call set up request addressing information of a VoIP driver 
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(114) in the gateway server (31). 

9. A method according to claim 5, further comprising the step of restoring the 
configuration of the phantom port on the PBX (12) to forward calls directed to the 
phantom port to the IP telephone (41 ). . 
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